Mobility Management Entity Configuration

 

This chapter provides configuration information for the Mobility Management Entity (MME).

Because each wireless network is unique, the system is designed with a variety of parameters allowing it to perform in various wireless network environments. In this chapter, only the minimum set of parameters are provided to make the system operational. Optional configuration commands specific to the MME product are located in the Command Line Interface Reference.

The following procedures are located in this chapter:

•	Configuring the System as a Standalone MME (base configuration)

•	Configuring Optional Features on the MME

Important: At least one Packet Services Card (PSC/PSC2) must be made active prior to service configuration. Information and instructions for configuring PSCs/PSC2s to be active can be found in the Configuring System Settings chapter of the System Administration Guide.

Caution: While configuring any base-service or enhanced feature, it is highly recommended to avoid conflicting or blocked IP addresses and port numbers when binding or assigning these to your configuration. In association with some service steering or access control features, the use of inappropriate port numbers may result in communication loss. Refer to the respective feature configuration document carefully before assigning any port number or IP address for communication with internal or external networks.

Important: Information about all commands in this chapter can be found in the Command Line Interface Reference.

Configuring the System as a Standalone MME (base configuration)

This section provides a high-level series of steps and associated configuration file examples for configuring the system to perform as an MME in a test environment. For a more robust configuration example, refer to the Sample Configuration Files appendix.

The configuration in this section assumes the following:

•	A single context for all interfaces and services (excepting the Local context)

•	static S-GW/P-GW selection (MME Policy configuration)

Information provided in this section includes the following:

•	Information Required

•	MME Configuration

Information Required

The following sections describe the minimum amount of information required to configure and make the MME operational on the network. To make the process more efficient, it is recommended that this information be available prior to configuring the system.

There are additional configuration parameters that are not described in this section. These parameters deal mostly with fine-tuning the operation of the S-GW in the network. Information on these parameters can be found in the appropriate sections of the Command Line Interface Reference.

Required MME Context Configuration Information

The following table lists the information that is required to configure the MME context.

Required Information for MME Context Configuration

Required Information	Description
MME context name	An identification string from 1 to 79 characters (alpha and/or numeric) by which the MME context is recognized by the system.
S1-MME Interface Configuration (To/from eNodeB)
Interface name	An identification string between 1 and 79 characters (alpha and/or numeric) by which the interface is recognized by the system. Multiple names are needed if multiple interfaces will be configured.
IP address and subnet	IPv4 or IPv6 address assigned to the S1-MME interface. This address will be used for binding the SCTP (local bind address(es)) to communicate with the eNodeBs using S1-AP. Multiple addresses and subnets are needed if multiple interfaces will be configured.
Physical port number	The physical port to which the interface will be bound. Ports are identified by the chassis slot number where the line card resides followed by the number of the physical connector on the card. For example, port 17/1 identifies connector number 1 on the card in slot 17. A single physical port can facilitate multiple interfaces.
S11 Interface Configuration (To/from S-GW)
Interface name	An identification string between 1 and 79 characters (alpha and/or numeric) by which the interface is recognized by the system. Multiple names are needed if multiple interfaces will be configured.
IP address and subnet	IPv4 address assigned to the S11 interface. Multiple addresses and subnets are needed if multiple interfaces will be configured.
Physical port number	The physical port to which the interface will be bound. Ports are identified by the chassis slot number where the line card resides followed by the number of the physical connector on the card. For example, port 17/1 identifies connector number 1 on the card in slot 17. A single physical port can facilitate multiple interfaces.
S6a Interface Configuration (To/from HSS)
Interface name	An identification string between 1 and 79 characters (alpha and/or numeric) by which the interface is recognized by the system. Multiple names are needed if multiple interfaces will be configured.
IP address and subnet	IPv4 or IPv6 addresses assigned to the S6a interface. Multiple addresses and subnets are needed if multiple interfaces will be configured.
Physical port number	The physical port to which the interface will be bound. Ports are identified by the chassis slot number where the line card resides followed by the number of the physical connector on the card. For example, port 17/1 identifies connector number 1 on the card in slot 17. A single physical port can facilitate multiple interfaces.
S6a Diameter Endpoint Configuration
End point name	An identification string from 1 to 63 characters (alpha and/or numeric) by which the S6a Diameter endpoint configuration is recognized by the system.
Origin realm name	An identification string between 1 through 127 characters. The realm is the Diameter identity. The originator’s realm is present in all Diameter messages and is typically the company or service name.
Origin host name	An identification string from 1 to 255 characters (alpha and/or numeric) by which the S6a origin host is recognized by the system.
Origin host address	The IP address of the S6a interface.
Peer name	The S6a endpoint name described above.
Peer realm name	The S6a origin realm name described above.
Peer address and port number	The IP address and port number of the HSS.
Route-entry peer	The S6a endpoint name described above.
S13 Interface Configuration (To/from EIR)
Interface name	An identification string between 1 and 79 characters (alpha and/or numeric) by which the interface is recognized by the system. Multiple names are needed if multiple interfaces will be configured.
IP address and subnet	IPv4 or IPv6 addresses assigned to the S13 interface. Multiple addresses and subnets are needed if multiple interfaces will be configured.
Physical port number	The physical port to which the interface will be bound. Ports are identified by the chassis slot number where the line card resides followed by the number of the physical connector on the card. For example, port 17/1 identifies connector number 1 on the card in slot 17. A single physical port can facilitate multiple interfaces.
S13 Diameter Endpoint Configuration
End point name	An identification string from 1 to 63 characters (alpha and/or numeric) by which the S13 Diameter endpoint configuration is recognized by the system.
Origin realm name	An identification string between 1 through 127 characters. The realm is the Diameter identity. The originator’s realm is present in all Diameter messages and is typically the company or service name.
Origin host name	An identification string from 1 to 255 characters (alpha and/or numeric) by which the S13 origin host is recognized by the system.
Origin host address	The IP address of the S13 interface.
Peer name	The S13 endpoint name described above.
Peer realm name	The S13 origin realm name described above.
Peer address and port number	The IP address and port number of the EIR.
Route-entry peer	The S13 endpoint name described above.
MME Service Configuration
MME service name	An identification string from 1 to 63 characters (alpha and/or numeric) by which the MME service can be identified on the system. It is configured in the Context configuration mode. Multiple names are needed if multiple MME services will be configured.
PLMN identifier	The identifier of Public Land Mobile Network (PLMN) of which MME belongs to. PLMN identifier is consisting of MCC and MNC.
MME identifier	The identifier of MME node. The MME Id is consisting of MME group and MME code.
TAI management database name	An identification string from 1 to 64 characters (alpha and/or numeric) by which the TAI management database service can be associated with the MME service. This is required for static S-GW selection. Refer to the Required MME Policy Configuration Information section below.
P-GW IP address	IPv4 or IPv6 address of a PDN Gateway (P-GW). This is required for static S-GW/P-GW selection.
eGTP Service Configuration
eGTP service name	An identification string from 1 to 63 characters (alpha and/or numeric) by which the eGTP service can be associated with MME system. Multiple names are needed if multiple eGTP services will be used.
Interface type	Identifies the type of interface to which the eGTP service is bound. This interface type is “interface-mme”.
GTP-C binding IP address	The IPv4 address of the S11 interface.
HSS Peer Service Configuration
HSS peer service name	An identification string from 1 to 63 characters (alpha and/or numeric) by which the HSS peer service is recognized by the system. Multiple names are needed if multiple HSS peer services will be used.
Diameter HSS peer	The name for a pre-configured Diameter endpoint, configured on system to associate with this MME service to access an HSS and an EIR. This is the S6a Diameter endpoint name.

‌

Required MME Policy Configuration Information

The following table lists the information that is required to configure the MME Policy on an MME.

Required Information for MME Policy Configuration

Required Information	Description
Tracking Area Identifier (TAI) management database name	An identification string from 1 to 64 characters (alpha and/or numeric) by which the TAI management database is recognized by the system.
Tracking Area Identifier (TAI) management object name	An identification string from 1 to 64 characters (alpha and/or numeric) by which the TAI management object is recognized by the system.
MCC, MNC, and TAC	The Mobile Country Code, Mobile Network Code, and Tracking Area Code for the S-GW this management object represents.
S-GW IP address	The IPv4 or IPv6 address of the S-GW this management object represents.

‌

How This Configuration Works

The following figure and supporting text describe how this configuration with a single context is used by the system to process a subscriber call originating from the GTP LTE network.

1.	The eNodeB forwards an Attach Request message from the UE to the MME containing the IMSI, last visited TAI (if available), the UE’s core network capability, the PDN Type, and the Attach Type.

2.	The MME service receives the Attach Request message and references the HSS peer service for authentication and location resolution.

3.	The HSS peer service configuration specifies the Diameter configuration and S6a interface to use to communicate with the HSS and the Diameter configuration and S13 interface to use to communicate with the Equipment Identity Register (EIR).

4.	Assuming that the MME has no previous security context, it sends an S6a Authentication Request to the HSS and uses the authentication vectors received in the response to complete the authentication procedure with UE.

5.	After authentication, the MME proceeds to do a security setup with the UE. During this procedure, the ME identity is transferred to the MME which then queries the EIR.

6.	The MME then sends an Update Location Request to the HSS and obtains relevant subscription data for the IMSI in the response.

7.	The MME policy is accessed to determine the S-GW and P-GW to which the UE should be attached.

8.	The MME uses the S11 interface bound to the eGTP service to communicate with the S-GW specified by the MME policy configuration.

9.

The MME then sends a Create Session Request to S-GW which is also forwarded to the specified P-GW (assuming GTP-S5/S8) P-GW establishes the S5/S8 GTPU bearers and then responds with a Create-Session-response which is forwarded to the MME by the S-GW. The S-GW includes the relevant S1-U bearer information.

10.

The MME then sends a NAS Attach Accept embedded in the S1 Init Ctxt Setup request to the eNodeB. The Attach Accept contains the IP address allocated to the PDN and the temporary identifier (GUTI) assigned to the UE. The MME waits for positive acknowledgement from both the eNodeB (Init Ctxt Setup response) and UE (Attach Complete). The Init Ctxt Setup Response contains the S1-U bearer endpoint information. The MME then uses the S11 Modify Bearer Request to update the eNodeB endpoints with the S-GW. The receipt of the S11 Modify Bearer Response completes the end-to-end bearer setup.

11.	The MME then uses the S6a Notify Request to update the HSS with the APN and P-GW identity.

MME Configuration

To configure the system to perform as a standalone eGTP S-GW, review the following graphic and subsequent steps.

Step 1

Set system configuration parameters such as activating PSCs by applying the example configurations found in the System Administration Guide.

Step 2

Create the MME context, service, and all interfaces, and bind the S1-MME interface to an IP address by applying the example configuration in the Creating and Configuring the MME Context and Service section.

Step 3

Create the eGTP service and associate it with the S11 interface by applying the example configuration in the Creating and Configuring the eGTP Service and Interface Association section.

Step 4

Create the HSS peer service and associate it with the S6a interface and S13 interface by applying the example configuration in the Creating and Configuring the HSS Peer Service and Interface Associations section.

Step 5

Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

Creating and Configuring the MME Context and Service

Use the following example to configure the MME context and all supported interfaces:

configure

   context <mme_context_name> -noconfirm

      interface <s1-mme_intf_name>

         ip address <ipv4_address>

         exit

      interface <s11_intf_name>

         ip address <ipv4_address>

         exit

      interface <s6a_intf_name>

         ip address <ipv4_address>

         exit

      interface <s13_intf_name>

         ip address <ipv4_address>

         exit

      mme-service <mme_svc_name> -noconfirm

         mme-id group-id <grp_id> mme-code <mme_code>

         plmn-id mcc <mcc_value> mnc <mnc_value>

         network-sharing plmnid mcc <mcc_value> mnc <mnc_value> mme-id group-id <id> mme-code <code>

         associate egtp-service <egtp-service_name> context <mme_context_name>

         associate hss-peer-service <hss_peer_service_name> context <mme_context_name>

         policy attach imei-query-type imei-sv verify-equipment-identity

         pgw-address <pgw_ip_address>

         bind s1-mme ipv4-address <ip_address>

         exit

      exit

   port ethernet <slot_number/port_number>

      no shutdown

      bind interface <s1-mme_intf_name> <mme_context_name>

      end

Notes:

•	All interfaces in this configuration can also be specified as IPv6 addresses using the ipv6 address command.

•	Multi-homing is supported on the S1-MME and S6a interfaces. Refer to the Configuring SCTP Multi-homing Support section in this chapter for more information on configuring multi-homing for the S1-MME and/or S6a interface(s).

•	A maximum of 256 services (regardless of type) can be configured per system.

•	The bind s1-mme command can also be specified as an IPv6 address using the ipv6-address keyword.

•	The network-sharing command is used to configure an additional PLMN ID for this MME service.

•	The eGTP service is configured in the following section.

•	The HSS peer service is configured in the Creating and Configuring the HSS Peer Service and Interface Associations section.

•

In the above example, the mobile equipment identity (IMEI) is checked during the attach procedure. This is configured in the policy attach command. Another option is to check IMEI during the tracking area update (TAU). This can be accomplished instead of, or, in addition to, the EIR query during the attach procedure. To check during the TAU, use the policy tau command.

•	The pgw-address command is used to statically configure P-GW discovery.

Creating and Configuring the eGTP Service and Interface Association

Use the following example to create an eGTP service and associate it with the S11 interface.

configure

   context <mme_context_name>

      egtp-service <egtp_service_name>

         interface-type interface-mme

         gtpc bind ipv4-address <s11_infc_ip_address>

         exit

      exit

   port ethernet <slot_number/port_number>

      no shutdown

      bind interface <s11_interface_name> <mme_context_name>

      end

Notes:

•	The gtpc bind command can be specified as an IPv6 address using the ipv6-address keyword. The interface specified for S11 communication must also be the same IPv6 address.

Creating and Configuring the HSS Peer Service and Interface Associations

Use the following example to create and configure the HSS peer service:

configure

   context <mme_context_name>

      hss-peer-service hss_peer_service_name

         diameter hss-endpoint <hss_endpoint_name> eir-endpoint <eir-endpoint_name>

         exit

      exit

   diameter endpoint <hss-endpoint_name>

      origin realm <realm_name>

      origin host <name> address <S6a_interface_address>

      peer <peer_name> realm <realm_name> address <hss_ip_address>

      route-entry realm <realm_name> peer <peer_name>

      exit

   diameter endpoint <eir-endpoint_name>

      origin realm <realm_name>

      origin host <name> address <S13_interface_address>

      peer <peer_name> realm <realm_name> address <eir_ip_address>

      route-entry realm <realm_name> peer <peer_name>

      exit

   port ethernet <slot_number/port_number>

      no shutdown

      bind interface <s6a_interface_name> <mme_context_name>

      exit

   port ethernet <slot_number/port_number>

      no shutdown

      bind interface <s13_interface_name> <mme_context_name>

      end

Notes:

•	The origin host and peer commands can accept multiple IP addresses supporting multi-homing on each endpoint. Refer to the Configuring SCTP Multi-homing Support section for information on configuring SCTP multi-homing for the S6a interface.

Configuring Optional Features on the MME

The configuration examples in this section are optional and provided to cover the most common uses of the MME in a live network. The intent of these examples is to provide a base configuration for testing.

The following optional configurations are provided in this section:

•	Configuring Circuit Switched Falllback

•	Configuring Dual Address Bearers

•	Configuring Dynamic Peer Selection

•	Configuring Emergency Session Support

•	Configuring Gn/Gp Handover Capability

•	Configuring Inter-MME Handover Support

•	Configuring X.509 Certificate-based Peer Authentication

•	Configuring Dynamic Node-to-Node IP Security on the S1-MME Interface

•	Configuring ACL-based Node-to-Node IP Security on the S1-MME Interface

•	Configuring Load Balancing on the MME

•	Configuring Mobility Restriction Support

•	Configuring Optimized Paging

•	Configuring S4-SGSN Handover Capability

•	Configuring SCTP Multi-homing Support

•	Configuring Single Radio Voice Call Continuity Support

•	Configuring Static S-GW Pools

•	Configuring UMTS to LTE ID Mapping

•	Configuring User Location Information Reporting Support

Configuring Circuit Switched Fallback

The configuration example in this section creates an SGs interface and an SGs service for communicating with a Mobile Switching Center/Visitor Location Register (MSC/VLR) for Circuit Switched Fallback capability.

Important: Circuit Switched Fallback is a licensed feature and requires the purchase of the Circuit Switched Fallback feature license to enable it.

Use the following configuration example to enable Circuit Switched Fallback capability on the MME:

configure

   lte-policy

      tai-mgnt-db <db_name>

         tai-mgmt-obj <object_name>

            lai mcc <number> mnc <number> lac <area_code>

            tai mcc <number> mnc <number> tac <area_code>

            exit

         exit

      exit

   context <mme_context_name> -noconfirm

      interface <sgs_intf_name>

         ip address <ipv4_address>

         exit

      sgs-service <name> -noconfirm

         sctp port <port_number>

         tac-to-lac-mapping tac <value> map-to lac <value> +

         vlr <vlr_name> ipv4-address <ip_address> port <port_number>

         pool-area <pool_name>

            lac <area_code> +

            hash-value non-configured-value use-vlr <vlr_name>

            hash-value range <value> to <value> use-vlr <vlr_name>

            exit

         bind ipv4-address <sgs-intf_ipv4_address>

         exit

      mme-service <service_name>

         associate tai-mgmt-db <db_name>

         associate sgs-service <sgs_svc_name>

         end

Notes:

•	The SGs IP address can also be specified as an IPv6 address. To support this, the ip address command can be changed to the ipv6 address command and the bind ipv4-address command can be changed to bind ipv6-address command.

This command also allows for the configuration of a secondary IP address in support of SCTP multi-homing.

•	Multiple TAC-to LAC values can be entered in the same configuration line.

•	Multiple LAC values can be entered in the same configuration line.

•	The VLR interface (vlr command) also supports IPv6 addressing and SCTP multi-homing.

Configuring Dual Address Bearers

This example configures support for IPv4/v6 PDNs.

Use the following configuration example to enable support on the MME for dual-address bearers:

configure

   context <mme_context_name> -noconfirm

      mme-service <mme_svc_name>

         policy network dual-addressing-support

         end

Configuring Dynamic Peer Selection

The configuration in this section replaces static configurations on the MME for the following peer components: MME, P-GW, S-GW, SGSN.

Use the following example to configure dynamic P-GW, S-GW, and peer MME selection through a DNS interface:

configure

   context <mme_context_name> -noconfirm

      interface <dns_intf_name>

         ip address <ipv4_address>

         exit

      ip domain-lookup

      ip name-servers <dns_ip_address>

      dns-client <name>

         bind address <dns_intf_ip_address>

         exit

      mme-service <mme_svc_name>

         dns pgw

         dns sgw

         dns peer-mme

         dns peer-sgsn

         end

Notes:

•	For the dns pgw, dns sgw, dns peer-mme, and dns peer-sgsn commands, the DNS client service must exist in the same context as the MME service. If the DNS client resides in a different context, the contex <ctx_name> command/variable must be added to the command(s).

Configuring Emergency Session Support

The configuration example in this section enables emergency bearer session support on the MME.

Use the following configuration example to enable emergency bearer services on the MME:

configure

   lte-policy

      lte-emergency-profile <profile_name>

         ambr max-ul <bitrate> max-dl <bitrate>

         apn <apn_name> pdn-type <type>

         pgw ip-address <address> protocol <type> weight <value>

         qos qci <qci> arp <arp_value> preemption-capability <capability> vulnerability <type>

         ue-validation-level <type>

         exit

      mme-service <mme_svc_name>

         associate lte-emergency-profile <profile_name>

         end

Notes:

•	A maximum of four LTE emergency profiles can be configured on the system.

•	In the apn command, the valid PDN types are: ipv4, ipv4v6, and ipv6.

•	In the pgw command, the valid protocol types are: both, gtp, and pmip. A maximum of four P-GW IP addresses can be configured per profile. An FQDN can also be configured in place of the IP addresses but only one P-GW FQDN can be configured per profile.

•	In the qos command, the valid preemption capabilities are: may and shall not. The valid vulnerability types are: not-preemptable and preemptable.

•	The ue-validation-level types are: auth-only, full, imsi, and none.

•	To configure the MME to ignore the IMEI validation of the equipment during the attach procedure in emergency cases, use the following command in the mme-service configuration mode:

policy attach imei-query-type <imei | imei-sv | none> verify-equipment-identity verify-emergency

•	To configure the MME to ignore the IMEI validation of the equipment during TAU procecures in emergency cases, use the following command in the mme-service configuration mode:

policy tau imei-query-type <imei | imei-sv | none> verify-equipment-identity verify-emergency

Configuring Gn/Gp Handover Capability

The example configuration in this section provides 3G to 4G handover capabilities between the MME and a Gn/Gp SGSN. The configuration creates the Gn interface used for control signalling during the handover.

Use the following configuration example to create a Gn interface and configure the control interface on the MME for Gn/Gp handovers:

configure

   context <mme_context_name> -noconfirm

      interface <Gn_intf_name>

         ip address <ipv4_address>

         exit

      sgtp-service <sgtp_svc_name>

         gtpc bind address <Gn_intf_ip_address>

         exit

      mme-service <mme_svc_name>

         associate sgtpc-service <sgtp_svc_name>

         peer-sgsn rai mcc <mcc_value> mnc <mnc_value> rac <value> lac <value> address <ip_address> capability gn

         nri length <length> plmn-id mcc <mcc_value> mnc <mnc_value>

         end

Notes:

•	The peer-sgsn command is used to statically configure a peer SGSN. SGSN selection can also be performed dynamically through the DNS client. For more information about dynamic peer selection, refer to the Configuring Dynamic Peer Selection section in this chapter.

•	If dynamic peer-SGSN selection is configured, an additional gtpc command must be added to the SGTP service: gtpc dns-sgsn contex <cntxt_name>

•	In the absence of an NRI length configuration, the MME treats the NRI as invalid. The MME will use a plain RAI-based FQDN (and not an NRI-based FQDN) for DNS queries made to resolve the source SGSN.

Configuring Inter-MME Handover Support

Use the following example to configure inter-MME handover support:

 

configure

   context <mme_context_name> -noconfirm

      interface <s10_intf_name>

         ip address <ipv4_address>

         exit

      egtp-service <egtp_service_name>

         interface-type interface-mme

         gtpc bind ipv4-address <s10_infc_ip_address>

         exit

      exit

      mme-service <mme_svc_name>

         peer-mme gummei mcc <number> mnc <number> group-id <id> mme-code <code> address <ipv4_address>

         exit

      exit

   port ethernet <slot_number/port_number>

      no shutdown

      bind interface <s10_interface_name> <mme_context_name>

      end

Notes:

•	The S10 IP address can also be specified as an IPv6 address. To support this, the ip address command can be changed to the ipv6 address command.

•	The peer-mme command can also be configured to acquire a peer MME through the use of a TAI match as shown in this command example:

peer-mme tai-match priority <value> mcc <number> mnc <number> tac any address <ipv4_address>

•	The peer-mme command is used to statically configure a peer MME. MME selection can also be performed dynamically through the DNS client. For more information about dynamic peer selection, refer to the Configuring Dynamic Peer Selection section in this chapter.

•	The peer MME IP address can also be specified as an IPv6 address.

Configuring X.509 Certificate-based Peer Authentication

The configuration example in this section enables X.509 certificate-based peer authentication, which can be used as the authentication method for IP Security on the MME.

Important: Use of the IP Security feature requires that a valid license key be installed. Contact your local Sales or Support representative for information on how to obtain a license.

The following configuration example enables X.509 certificate-based peer authentication on the MME.

In Global Configuration Mode, specify the name of the X.509 certificate and CA certificate, as follows:

configure

   certificate name <cert_name> pem url <cert_pem_url> private-key pem url <private_key_url>

   ca-certificate name <ca_cert_name> pem url <ca_cert_url>

   end

Notes:

•	The certificate name and ca-certificate list ca-cert-name commands specify the X.509 certificate and CA certificate to be used.

•	The PEM-formatted data for the certificate and CA certificate can be specified, or the information can be read from a file via a specified URL as shown in this example.

When creating the crypto template for IPSec in the Context Configuration Mode, bind the X.509 certificate and CA certificate to the crypto template and enable X.509 certificate-based peer authentication for the local and remote nodes, as follows:

configure

   context <mme_context_name>

      crypto template <crypto_template_name> ikev2-dynamic

         certificate name <cert_name>

         ca-certificate list ca-cert-name <ca_cert_name>

         authentication local certificate

         authentication remote certificate

         end

Notes:

•	A maximum of sixteen certificates and sixteen CA certificates are supported per system. One certificate is supported per service, and a maximum of four CA certificates can be bound to one crypto template.

•	The certificate name and ca-certificate list ca-cert-name commands bind the certificate and CA certificate to the crypto template.

•	The authentication local certificate and authentication remote certificate commands enable X.509 certificate-based peer authentication for the local and remote nodes.

Configuring Dynamic Node-to-Node IP Security on the S1-MME Interface

The configuration example in this section creates an IKEv2/IPSec dynamic node-to-node tunnel endpoint on the S1-MME interface.

Important: Use of the IP Security feature requires that a valid license key be installed. Contact your local Sales or Support representative for information on how to obtain a license.

The following configuration examples are included in this section:

•	Creating and Configuring an IPSec Transform Set

•	Creating and Configuring an IKEv2 Transform Set

•	Creating and Configuring a Crypto Template

•	Binding the S1-MME IP Address to the Crypto Template

Creating and Configuring an IPSec Transform Set

 

The following example configures an IPSec transform set which is used to define the security association that determines the protocols used to protect the data on the interface:

configure

   context <mme_context_name>

      ipsec transform-set <ipsec_transform-set_name>

         encryption aes-cbc-128

         group none

         hmac sha1-96

         mode tunnel

         end

Notes:

•	The encryption algorithm, aes-cbc-128, or Advanced Encryption Standard Cipher Block Chaining, is the default algorithm for IPSec transform sets configured on the system.

•	The group none command specifies that no crypto strength is included and that Perfect Forward Secrecy is disabled. This is the default setting for IPSec transform sets configured on the system.

•	The hmac command configures the Encapsulating Security Payload (ESP) integrity algorithm. The sha1-96 keyword uses a 160-bit secret key to produce a 160-bit authenticator value. This is the default setting for IPSec transform sets configured on the system.

•	The mode tunnel command specifies that the entire packet is to be encapsulated by the IPSec header including the IP header. This is the default setting for IPSec transform sets configured on the system.

Creating and Configuring an IKEv2 Transform Set

 

The following example configures an IKEv2 transform set:

configure

   context <mme_context_name>

      ikev2-ikesa transform-set <ikev2_transform-set_name>

         encryption aes-cbc-128

         group 2

         hmac sha1-96

         lifetime <sec>

         prf sha1

         end

Notes:

•	The encryption algorithm, aes-cbc-128, or Advanced Encryption Standard Cipher Block Chaining, is the default algorithm for IKEv2 transform sets configured on the system.

•	The group 2 command specifies the Diffie-Hellman algorithm as Group 2, indicating medium security. The Diffie-Hellman algorithm controls the strength of the crypto exponentials. This is the default setting for IKEv2 transform sets configured on the system.

•	The hmac command configures the Encapsulating Security Payload (ESP) integrity algorithm. The sha1-96 keyword uses a 160-bit secret key to produce a 160-bit authenticator value. This is the default setting for IKEv2 transform sets configured on the system.

•	The lifetime command configures the time the security key is allowed to exist, in seconds.

•

The prf command configures the IKE Pseudo-random Function, which produces a string of bits that cannot be distinguished from a random bit string without knowledge of the secret key. The sha1 keyword uses a 160-bit secret key to produce a 160-bit authenticator value. This is the default setting for IKEv2 transform sets configured on the system.

Creating and Configuring a Crypto Template

 

The following example configures an IKEv2 crypto template:

configure

   context <mme_context_name>

      crypto template <crypto_template_name> ikev2-dynamic

         authentication local pre-shared-key key <text>

         authentication remote pre-shared-key key <text>

         ikev2-ikesa transform-set list <name1> . . . <name6>

         ikevs-ikesa rekey

         payload <name> match childsa match ipv4

            ipsec transform-set list <name1> . . . <name4>

            rekey

            end

Notes:

•	The ikev2-ikesa transform-set list command specifies up to six IKEv2 transform sets.

•	The ipsec transform-set list command specifies up to four IPSec transform sets.

Binding the S1-MME IP Address to the Crypto Template

 

The following example configures the binding of the S1-MME interface to the crypto template:

configure

   context <mme_context_name>

      mme-service <mme_svc_name>

         bind s1-mme ipv4-address <address> ipv4-address <address> crypto-template <enodeb_crypto_template>

         end

Notes:

•	The bind command in the MME service configuration can also be specified as an IPv6 address using the ipv6-address command.

•	This example shows the bind command using multi-homed addresses. The multi-homing feature also supports the use of IPv6 addresses.

Configuring ACL-based Node-to-Node IP Security on the S1-MME Interface

The configuration example in this section creates an IKEv2/IPSec ACL-based node-to-node tunnel endpoint on the S1-MME interface.

Important: Use of the IP Security feature requires that a valid license key be installed. Contact your local Sales or Support representative for information on how to obtain a license.

The following configuration examples are included in this section:

•	Creating and Configuring a Crypto Access Control List

•	Creating and Configuring an IPSec Transform Set

•	Creating and Configuring an IKEv2 Transform Set

•	Creating and Configuring a Crypto Map

Creating and Configuring a Crypto Access Control List

 

The following example configures a crypto ACL (Access Control List), which defines the matching criteria used for routing subscriber data packets over an IPSec tunnel:

configure

   context <mme_context_name>

      ip access-list <acl_name>

         permit tcp host <source_host_address> host <dest_host_address>

         end

Notes:

•	The permit command in this example routes IPv4 traffic from the server with the specified source host IPv4 address to the server with the specified destination host IPv4 address.

Creating and Configuring an IPSec Transform Set

 

The following example configures an IPSec transform set which is used to define the security association that determines the protocols used to protect the data on the interface:

configure

   context <mme_context_name>

      ipsec transform-set <ipsec_transform-set_name>

         encryption aes-cbc-128

         group none

         hmac sha1-96

         mode tunnel

         end

Notes:

•	The encryption algorithm, aes-cbc-128, or Advanced Encryption Standard Cipher Block Chaining, is the default algorithm for IPSec transform sets configured on the system.

•	The group none command specifies that no crypto strength is included and that Perfect Forward Secrecy is disabled. This is the default setting for IPSec transform sets configured on the system.

•	The hmac command configures the Encapsulating Security Payload (ESP) integrity algorithm. The sha1-96 keyword uses a 160-bit secret key to produce a 160-bit authenticator value. This is the default setting for IPSec transform sets configured on the system.

•	The mode tunnel command specifies that the entire packet is to be encapsulated by the IPSec header including the IP header. This is the default setting for IPSec transform sets configured on the system.

Creating and Configuring an IKEv2 Transform Set

 

The following example configures an IKEv2 transform set:

configure

   context <mme_context_name>

      ikev2-ikesa transform-set <ikev2_transform-set_name>

         encryption aes-cbc-128

         group 2

         hmac sha1-96

         lifetime <sec>

         prf sha1

         end

Notes:

•	The encryption algorithm, aes-cbc-128, or Advanced Encryption Standard Cipher Block Chaining, is the default algorithm for IKEv2 transform sets configured on the system.

•	The group 2 command specifies the Diffie-Hellman algorithm as Group 2, indicating medium security. The Diffie-Hellman algorithm controls the strength of the crypto exponentials. This is the default setting for IKEv2 transform sets configured on the system.

•	The hmac command configures the Encapsulating Security Payload (ESP) integrity algorithm. The sha1-96 keyword uses a 160-bit secret key to produce a 160-bit authenticator value. This is the default setting for IKEv2 transform sets configured on the system.

•	The lifetime command configures the time the security key is allowed to exist, in seconds.

•

The prf command configures the IKE Pseudo-random Function which produces a string of bits that cannot be distinguished from a random bit string without knowledge of the secret key. The sha1 keyword uses a 160-bit secret key to produce a 160-bit authenticator value. This is the default setting for IKEv2 transform sets configured on the system.

Creating and Configuring a Crypto Map

 

The following example configures an IKEv2 crypto map:

configure

   context <mme_context_name>

      crypto map <crypto_map_name> ikev2-ipv4

         match address <acl_name>

         peer <ipv4_address>

         authentication local pre-shared-key key <text>

         authentication remote pre-shared-key key <text>

         ikev2-ikesa transform-set list <name1> . . . <name6>

         payload <name> match ipv4

            lifetime <seconds>

            ipsec transform-set list <name1> . . . <name4>

            exit

         exit

      interface <s1-mme_intf_name>

         ip address <ipv4_address>

         crypto-map <crypto_map_name>

         exit

      exit

   port ethernet <slot_number/port_number>

      no shutdown

      bind interface <s1-mme_intf_name> <mme_context_name>

      end

Notes:

•	The type of crypto map used in this example is IKEv2-IPv4 for IPv4 addressing. An IKEv2-IPv6 crypto map can also be used for IPv6 addressing.

•	The ipsec transform-set list command specifies up to four IPSec transform sets.

Configuring Load Balancing on the MME

In networks that contain multiple MMEs configured as a pool, load balancing is a necessary feature allowing UE attachments to be spread accross the pool instead of a small number of MMEs.

The following example configures load balancing on an MME:

configure

   context <mme_context_name>

      mme-service <mme_svc_name>

         relative-capacity <number>

         end

Notes:

•	The relative-capacity command specifies a weight factor used in comparing the capacity of the MME to other MMEs in a pool.

Configuring Mobility Restriction Support

Mobility or handover restriction is performed by handover restriction lists configured on the MME. These lists restrict inter-RAT, 3G location area, and/or 4G tracking area handovers based on the configuration in the Handover Restriction List Configuration Mode.

Important: Mobility restriction support is only available through the operator policy configuration. For more information on operator policy, refer to the Operator Policy chapter in this guide.

Configuring Inter-RAT Handover Restrictions on the MME

Inter-RAT handover restriction configurations on the MME restrict subscribers from participating in handovers to defined radio access network types.

Use the following example to configure this feature:

configure

   lte-policy

      ho-restrict-list <name>

         forbidden inter-rat cdma2000

         end

Notes:

•	Other forbidden inter-RAT choices are: all, GERAN, and UNTRAN.

•	This configuration will only become operational when it is associated with a call control profile. Only one handover restriction list can be associated with a call control profile.

Configuring Location Area Handover Restrictions on the MME

Location area handover restriction lists on the MME restrict subscribers from participating in handovers to specific 3G location area codes.

Use the following example to configure this feature:

configure

   lte-policy

      ho-restrict-list <name>

         forbidden location-area plmnid <id>

            lac <area_code> <area_code> <area_code> +

            end

Notes:

•	Up to 16 forbidden location areas can be configured per handover restriction list.

•	Up to 128 location area codes can be entered in a single lac command line.

•	This configuration will only become operational when it is associated with a call control profile. Only one handover restriction list can be associated with a call control profile.

Configuring Tracking Area Handover Restrictions on the MME

Tracking area handover restriction lists on the MME restrict subscribers from participating in handovers to specific 4G tracking area codes.

Use the following example to configure this feature:

configure

   lte-policy

      ho-restrict-list <name>

         forbidden tracking-area plmnid <id>

            tac <area_code> <area_code> <area_code> +

            end

Notes:

•	Up to 16 forbidden tracking areas can be configured per handover restriction list.

•	Up to 128 tracking area codes can be entered in a single tac command line.

•	This configuration will only become operational when it is associated with a call control profile. Only one handover restriction list can be associated with a call control profile.

Configuring Optimized Paging

The example configuration in this section allows the MME to perform optimized, idle-mode paging, reducing the number of messages carried over the E-UTRAN access network.

Important: Optimized Paging is a licensed feature and requires the purchase of the Optimized Paging feature license to enable it.

The following configuration example enables optimized paging on the MME:

configure

   context <mme_context_name>

      mme-service <mme_svc_name>

         heuristic-paging

         end

Configuring S4-SGSN Handover Capability

This configuration example configures an S3 interface supporting inter-RAT handovers between the MME and an S4-SGSN.

Use the following example to configure this feature:

configure

   context <mme_context_name> -noconfirm

      interface <s3_interface_name>

         ip address <ipv4_address>

         exit

      mme-service <mme_svc_name>

         peer-sgsn rai mcc <mcc_value> mnc <mnc_value> rac <value> lac <value> address <ip_address> capability s3

         nri length <length> plmn-id mcc <mcc_value> mnc <mnc_value>

         exit

      exit

   port ethernet <slot_number/port_number>

      no shutdown

      bind interface <s3_interface_name> <mme_context_name>

      end

Notes:

•	The S3 IP address can also be specified as an IPv6 address. To support this, the ip address command can be changed to the ipv6 address command.

•	The peer-sgsn command is used to statically configure a peer SGSN. SGSN selection can also be performed dynamically through the DNS client. For more information about dynamic peer selection, refer to the Configuring Dynamic Peer Selection section in this chapter.

•	In the absence of an NRI length configuration, the MME treats the NRI as invalid. The MME will use a plain RAI-based FQDN (and not an NRI-based FQDN) for DNS queries made to resolve the source SGSN.

Configuring SCTP Multi-homing Support

SCTP multi-homing can be configured on the S1-MME interface (to/from eNodeB), the S6a interface (to/from HLR/HSS), and the SGs interface (to/from the MSC/VLR).

Configuring SCTP Multi-homing on the S1-MME Interface

Up to two IPv4 or IPv6 addresses for the S1-MME interface can be entered to allow for SCTP multi-homing.

The configuration example in this section is intended as a replacement for the S1-MME interface configuration located in the Creating and Configuring the MME Context and Service section. Use the following example to configure S1-MME multi-homing between the MME and the eNodeB:

configure

   context <mme_context_name> -noconfirm

      interface <s1-mme_intf_name>

         ip address <ipv4_address>

         ip address <secondary_ipv4_address>

         exit

      mme-service <mme_svc_name>

         bind s1-mme ipv4-address <ipv4_address> ipv4-address <secondary_ipv4_address>

         exit

      exit

   port ethernet <slot_number/port_number>

      no shutdown

      bind interface <s1-mme_intf_name> <mme_context_name>

      end

Notes:

•	The S1-MME IP addresses can also be specified as IPv6 addresses using the ipv6 address keyword.

•	The IP addresses in the bind s1-mme ipv4-address command can also be specified as IPv6 addresses using the ipv6-address keyword.

Configuring SCTP Multi-homing on the S6a Interface

Up to four IPv4 or IPv6 addresses for the S6a interface can be configured to allow for SCTP multi-homing.

The configuration example in this section is intended as a replacement for the S6a interface configuration located in the Creating and Configuring the MME Context and Service section and the Diameter configuration for the S6a interface located in the Creating and Configuring the HSS Peer Service and Interface Associations section. Use the following example to configure S6a multi-homing between the MME and theHLR/HSS:

configure

   context <mme_context_name>

      interface <s6a_intf_name>

         ip address <s6a_intf_primary_ip_addr> <ip_mask>

         ip address <s6a_intf_secondary_ip_addr2> <ip_mask> secondary

         ip address <s6a_intf_secondary_ip_addr3> <ip_mask> secondary

         exit

      exit

   diameter endpoint <hss-endpoint_name>

      origin realm <realm_name>

      origin host <name> address <s6a_intf_primary_ip_addr> port <number> address <s6a_intf_secondary_ip_addr2> port <number> address <s6a_intf_secondary_ip_addr3> port <number>

      peer <peer_name> realm <realm_name> address <hss_ip_addr1> port <number> address <hss_ip_addr2> port <number> sctp

      route-entry realm <realm_name> peer <peer_name>

      exit

   port ethernet <slot_number/port_number>

      no shutdown

      bind interface <s6a_intf_name> <mme_context_name>

      exit

Notes:

•	The S6a IP addresses can also be specified as IPv6 addresses using the ipv6 address keyword.

Configuring S6a SCTP and Application Timers for Multi-homing

In the event of a path failure, the SCTP multi-homing feature requires time to activate the alternate path. Timers associated with the SCTP heartbeat and the application; in this instance, a Diameter watchdog request, must be tuned properly to ensure that the application does not timeout before the redundant SCTP path can be activated. The required calculation is based on the two paths configured between the MME and the HSS, the maximum retransmission configuration for the SCTP paths, and the SCTP heartbeat timeout configuration. The configuration of the timers must be identical on both peers.

The recommended SCTP timer values are provided below in the first row for the Diameter application default values that follow the typical case of two paths between the MME and HSS SCTP peers. SCTP HB interval can be in the range of 1 to 10 seconds, since (10 sec x 1 retx x 2 paths = 20 seconds) < (30 sec watchdog timeout x 1 retry).

The second row displays the recommended configuration using the same Diameter defaults but providing a SCTP heartbeat timer that reduces heartbeat traffic.

SCTP/Application Timer Configuration Values

SCTP Heartbeat Timeout	SCTP Path Max Retransmissions	Diameter Device Watchdog Timeout	Diameter Watchdog Request Max Retries
1-10 range	1	30 (default)	1 (default)
5	1	30 (default)	1 (default)

‌

The following example configures the SCTP and application timers for the S6a SCTP interface supporting multi-homing:

configure

   sctp-param-template <name>

      sctp-max-path-retx <value>

      timeout sctp-heart-beat <value>

      exit

   context <name>

      diameter endpoint <endpoint_name>

         associate sctp-parameter-template <template_name>

         device-watchdog-request max-retries <retry_count>

         watchdog-timeout <timeout>

         end

Notes:

•	When no SCTP parameter template is associated with the Diameter endpoint, the following default values are used:

sctp-max-path-retx 10 (default in the parameter template is 5)

timeout sctp-heart-beat 30 (default for the parameter template as well)

Configuring SCTP Multi-homing on the SGs Interface

Up to two IPv4 or IPv6 addresses for the SGs interface can be entered to allow for SCTP multi-homing.

The configuration example in this section is intended as a replacement for the SGs interface configuration located in the Configuring Circuit Switched Falllback section. Use the following example to configure SGs multi-homing between the MME and the MSC/VLR:

configure

   context <mme_context_name> -noconfirm

      interface <s1-mme_intf_name>

         ip address <ipv4_address>

         ip address <secondary_ipv4_address>

         exit

      sgs-service <mme_svc_name>

         bind ipv4-address <ipv4_address> ipv4-address <secondary_ipv4_address>

         exit

      exit

   port ethernet <slot_number/port_number>

      no shutdown

      bind interface <sgs_intf_name> <mme_context_name>

      end

Notes:

•	The SGs IP addresses can also be specified as IPv6 addresses using the ipv6 address keyword.

•	The IP addresses in the bind ipv4-address command can also be specified as IPv6 addresses using the ipv6-address keyword.

Configuring Single Radio Voice Call Continuity Support

To support SRVCC functionality on the MME, an Sv reference point must be created providing an interface to the Mobile Switching Center (MSC) responsible for communicating with the MME during the handover process.

Use the following example to configure SRVCC support on the MME:

configure

   context <mme_context_name>

      interface <sv_intf_name>

         ip address <ipv4_address>

         exit

      egtp-service <egtpc_sv_service_name>

         interface-type interface-mme

         gtpc bind ipv4-address <sv_infc_ip_address>

         exit

      mme-service <mme_service_name>

         associate egtpc-sv-service <egtpc_sv_service_name>

         msc <ip_address>

         exit

      exit

   port ethernet <slot_number/port_number>

      no shutdown

      bind interface <sv_intf_name> <mme_context_name>

      end

Notes:

•	The gtpc bind command can be specified as an IPv6 address using the ipv6-address keyword. The interface specified for Sv communication must also be the same IP address type.

Configuring Static S-GW Pools

The MME supports static TAI list configuration which allows for the mapping of TAIs, TACs, and S-GWs to facilitate S-GW pooling for UEs moving between TAIs in their TAI lists.

Creating and Configuring a TAI Management Database and Object

This section provides configuration examples for creating and configuring the TAI/S-GW associations for S-GW pooling.

Use the following example to configure this feature on the MME:

configure

   lte-policy

      tai-mgmt-db <db_name>

         tai-mgmt-obj <object_name>

            tai mcc <number> mnc <number> tac <value>

            sgw-address <ipv4_address> s5-s8-protocol gtp weight <number>

            end

Notes:

•	Up to four databases can be configured on the system.

•	Up to 500 management objects can be configured per database.

•	Up to 16 TAIs can be configured per management object.

•	Up to 16 TACs can be configured per TAI.

•	The sgw-address variable can also be specified as an IPv6 address.

•	Up to 32 S-GW IP addresses can be configured per management object.

•	Weights for IPv4 addresses are ignored if IPv6 addresses are present meaning only IPv6 addresses are load-balanced if present.

•	The s5-s8-protocol can also be specified as pmip or both (GTP and PMIP).

Associating a TAI Management Database with an MME Service

In order for an MME service to use a statically configured S-GW pool, it must be associated with the TAI Management Database.

Use the following example to configure the TAI Management Database-to-MME service association:

configure

   context <mme_context_name>

      mme-service <mme_svc_name>

         associate tai-mgmt-db <database_name>

         end

Notes:

•	Only one TAI Management Database can be configured per MME service.

•	This association can also be performed in the Call Control Profile Configuration Mode supporting Operator Policy. If both associations are configured, the Operator Policy association is preferred by the system.

Associating a TAI Management Database with a Call Control Profile

MME service can access a statically configured S-GW pool through an Operator Policy instance, specifically through the Call Control Profile.

Use the following example to configure the TAI Management Database-to-MME service association:

configure

   call-control-profile <name>

      associate tai-mgmt-db <database_name>

      end

Notes:

•	Only one TAI Management Database can be configured per Call Control Profile.

•	This association can also be performed in the MME Service Configuration Mode. If both associations are configured, the Operator Policy association is preferred by the system.

Configuring UMTS to LTE ID Mapping

UMTS networks are configured with LACs allocated from the reserved space of 32K to 64K. In LTE networks, this space is typically reserved for MME group IDs. To overcome this issue during inter-RAT handovers, the MME can be configured with mappings between LACs and MME group IDs.

Use the following configuration example to map PLMN IDs to MME group IDs:

configure

   lte-policy

      network-global-mme-id-mgmt-db

         plmn mcc <mcc_value> mnc <mnc_value> mme-group-id-range first <id> last <id>

         exit

      exit

   context <mme_service_context>

      mme-service <service_name>

         associate network-global-mme-id-mgmt-db

         end

Notes:

•	Up to 32 mappings can be configured on the system.

•	Overlapping ranges can be identified in the output of the show configuration errors command.

Configuring User Location Information Reporting Support

This feature allows the MME to query and receive UE location reports from an eNodeB.

Important: User Location Information Reporting is a licensed feature and requires the purchase of the ULI Reporting feature license to enable it.

Use the following example to configure User Location Information (ULI) reporting support on the MME:

configure

   context <mme_context_name>

      mme-service <mme_svc_name>

         location-reporting

         end

 

 

Cisco Systems Inc.

Tel: 408-526-4000

Fax: 408-527-0883